• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    In a networked system, such as a telecommunications system having a first node connected to a second node, when each software file identifier identifies a corresponding one of the plurality of software files, supply the desired one or more software files to the second node. The technique to begin is with a first node retrieving a menu of software file identifiers. The software file identifier is passed to the second node, where each is examined and a response is formed for each. A response indicating whether the corresponding one of the plurality of software files is desired or not desired by one of the two is passed back to the first node. The first node examines the response and retrieves the desired software file. The retrieved software is passed from the first node to the second node. In another aspect of the invention, the indication that it is not desired is expanded to include an indication that the provided file has already been loaded or is prohibited from being loaded. In another aspect of the present invention, the steps of providing a menu, receiving a response, and sending a desired file are repeated in two phases each, so that in a first phase, the second node may have a more complex bootstrap program. You may need to download and start it. Then, during the second phase of the download, a more complex bootstrap program running at the second node determines if there are more subfiles to be accepted from the first node.
    公开号:KR19980701680A
    申请号:KR1019970705076
    申请日:1996-01-30
    公开日:1998-06-25
    发明作者:매쯔 하캔 다린；에릭슨，매쯔，얼란트；레프그렌，레나르트，닐스，아돌프
    申请人:얼링 블로메, 클라스 노린；텔레호낙티에볼라게트 엘엠 에릭슨；
    IPC主号:
    专利说明:

    Method and device for downloading the software
    The present invention relates to a system and method for downloading software files from one node to one or more other nodes in a communication system, in particular a base transceiver from a base station controller in a cellular telecommunication system. A system and method for downloading software to a station.
    The principle of operation of a mobile communication system such as a cellular telephone system is already known. Inherently, the system is divided into a ground base system and a wireless system. The mobile subscriber communicates with one of a plurality of base transceiver stations (BTSs) over an air interface. The BTS is geographically distributed such that when the mobile subscriber roams it is in the service area of at least one of the BTSs in the system. If the mobile subscriber moves out of range of the designated BTS and moves to the range of the adjacent BTS while the call is in progress, the cellular telephone system will redirect the mobile subscriber to the neighbor BTS in a process called handoff. Management of call handoffs, as well as all other features of call initiation and termination, are handled by the various components of the ground base system. The terrestrial base system is also responsible for routing the call between mobile subscribers and for interfacing calls to the public switched telephone network (PSTN).
    Many of the functions of terrestrial base systems are not executed by a single hardware unit, but instead are distributed among a plurality of components connected together in a communication network. This component includes the BTS described above that provides a radio link between the terrestrial base system and the mobile subscriber. The ground base system also includes a base station controller (BSC) that controls the high level operation of more than 100 BTSs. Switching, call handoff, and other functions are performed by a mobile switching center (MSC) connected to the BSC in the system.
    Referring to Figure 1 (a), the network typically includes BTS 103-1, ..., 103-n (hereinafter generally referred to as 103). The BTSs 103 need not be identical to one another and typically come in a variety of occurrences, types, and modifications as a result of repeated upgrades and / or system expansions with newer and improved units of equipment. Expansion includes the addition of new BTS 103 as a whole or the addition of new components such as transceivers. Upgrading means replacing parts such as transceivers and timing units.
    As described in FIG. 1 (a), the BTS 103 typically performs one or more transceivers (TRXs) and functions that are common to the BTS 103 as a whole and with a transceiver group manager called Base Station Central Functions (BCF). Similarly, several functional subunits (113-1-1), ..., (113-1-m 1 ), ..., (113-n-1), ..., (113-nm n ) (Hereinafter generally referred to as reference numeral 113). In general, each subunit 113 is controlled by its own computer 117 having its own memory. As described, the subunits 113 on the top level are each of the signal transmission paths 115-1-1, ..., 115-1-m1,..., Which are directly controllable by the BSC 101. ..., (115-n-1), ..., (115-n-mn) (hereinafter generally referred to as reference numeral 115). Signal transmission path 115 is comprised of dedicated pulse code modulation (PCM) time slots. Alternatively, the signal transmission path 115 may be implemented as an OSI Layer 2 data link using an PCM time slot (to be used as a physical layer) (OSI is intended for standardization). Standard data communication protocol recommended by the International Organization (ISO)). The OSI Layer 2 data link is multiplexed or concentrated in any way from one same PCM time slot to another subunit along with the other OSI Layer 2 data link. Such a link or dedicated PCM time slot is considered to be a direct signal transmission path 115 between the BSC 101 and the subunit 113. Apart from using the signal transmission path 115 for subunit control, it is also used to carry out signal transmission between the mobile station (not shown) and the BSC 101 connected to the BTS 103 via a wireless channel. .
    In the system as described above, the BTS 103, and its configuration subunit 113, is typically controlled by software (SW) 119 downloaded from the BSC 101. The downloaded software must be executed, for example, when the system is started. Other operations also require software download operations. For example, a new BTS 103 and a new component in the BTS 103 require a new application SW 119 that is different from the one previously operated in the BTS 103. This new SW 119 must be downloaded from the BSC 101 to the new or modified BTS 103. Moreover, even when the hardware (HW) in the system is not changed at all, the entire network or its components are also sometimes updated with a new (upgraded) application SW 119. In all other situations that require a SW download (eg, at startup, when replacing a HW unit, and also upon a pure SW update), other versions of the SW 119 must be downloaded to another BTS 103.
    Upgrading a system typically involves replacing or modifying some subunits 113 while leaving others unchanged. As a result, SW 119 that needs to be loaded into one BTS 103 is different from SW 119 associated with another BTS 103.
    In a conventional system, application software for a structure such as BTS 103 is a package 121 (hereinafter referred to as a subfile) of several files for each subunit. The BTS download is executed over the signal transmission path 115. In some implementations all paths are possibly used by the same software that is passed across all signal transmission paths 115. Alternatively, other software may be delivered to other subunits 113.
    In another network configuration such as that described in FIG. 1 (b), only one signal transmission path 115 is used for each BTS 103. This signal transmission path is terminated in the subunit 113-x-1 (1≤x≤n) that executes the BCF function. Further sending the SW 119 to the appropriate one of the remaining subunits 113-x-y (y1) in the BTS 103-x is executed by the internal communication network 123-x. This communication network 123-x has various limitations such that the method of distributing software subfiles from the BSC 101 becomes a matter of design choice. The optimal choice depends on the type or variant of the BTS 103 and changes when a newly upgraded SW release is presented.
    There are a plurality of inconveniences in this prior art software download method. Considering for a moment the method described in FIG. 1 (b) in which the BSC 101 delivers the SW package 121 to the BTS 103 via a single signal transmission path 115, the BSC 101 can determine which BTS is selected. It should still be known whether it should be downloaded to the SW package 121. In order to handle the update, even if only one subunit 113 is changed, there must be one new version of the SW package 121 for each variant of the BTS 103. Moreover, a suitably modified SW package 121 is entirely transmitted on all possible signal transmission paths 115. Since there are many subunits 113 and applications that can require somewhat independently updated SW, the number of package versions is rapidly increased. Thus, this method results in a waste of much increased transmission capacity, resulting in long download times. In this way also a waste of storage capacity is incurred, which places a lot of increased burden on the manual processing of the file running medium.
    Considering the method described in FIG. 1 (a) in which each subunit 113 has a dedicated signal transmission path 115 to receive the corresponding subfile, the BSC 101 determines which package 121 is loaded with which subs. Has a more cumbersome task to know if it is passed to unit 113. Each subunit 113 in the network should include the version level recorded in the BSC 101 which will provide the intended upgrade when considering variations. The dependence between versions on the other subunits 113 should also be known as the operating support system (OSS) by the version processing subsystem in the BSC 101 or manually, or in another feature of the prior art. Given the large amount of this kind of information, the manual data input, which is essentially required in some assignments, creates a source of potential error.
    <summary>
    It is an object of the present invention to provide an apparatus and method for distributing SW from one BSC to one or more BTSs that reduces the amount of BTS program code data that must be stored in the BSC.
    It is still another object of the present invention to provide a SW download technique that reduces the amount of BTS program code data to be sent to the BTS by sending only those parts that are strictly necessary to the BTS. This is not limited but includes the case where some SW is already stored in the BTS memory.
    Another object of the present invention is that a large portion of the SW is generally needed, or generally a lot, when the update is hardly affected for all SWs and when the update is to be applied to BTS types and / or variants. It is to provide a general and flexible SW download technique in the presence of continuous SW updates delivered to several variants and / or types of BTS populations. It is another object of the present invention to provide such a technique in an environment where SW file versions are rapidly increasing as well as types / modifications.
    Another object of the present invention is to eliminate the risk of human error when providing information to control which SWs are passed to which BTSs and which BTS subunits, and also to control which signal transmission paths are used for such downloads. It is to provide SW download technology. Another goal is to eliminate the risk of downloading incompatible SW subfiles on these systems.
    According to one aspect of the invention, the above and other objects are achieved in a networked system comprising a first node connected to a second node, for example a BSC connected to a BTS in a cellular telecommunication system. The method and apparatus of the present invention supply one or more desired software files to a second node in the following manner. At the first node, a menu containing a list of software file identifiers is retrieved, where each software file identifier identifies a corresponding one of the plurality of software files. The list of software file identifiers is then passed from the first node to the second node. At the second node, each software file identifier is examined. For each software file identifier, a response is formed that includes an indication of whether the corresponding one of the plurality of software files is desired or not desired by one of the two. According to another feature of the invention, the indication that the software file is not desired includes one of two indications that the software file has already been loaded or loaded prohibited. If the first node receives an indication that the software file has already loaded, to determine whether the software file should be downloaded to the second node despite the indication that the software has already loaded (ie, the download of the software file is Another process is executed to determine whether it should be forced to two nodes.
    The response is passed from the second node to the first node and examined. The first node retrieves one of the plurality of software files that corresponds to the software file identifier that was marked as desired by the second node. According to one aspect of the invention, when the first node is a BSC in a cellular telecommunications network, the desired software file is retrieved from storage means located in the BSC. In an alternative method embodiment, the BSC requires this from an OSS that locally stores the desired software file. After retrieving it from the local storage means, the OSS delivers the desired software file to the BSC.
    After retrieving the desired software file, the first node forwards it to the second node.
    In still another aspect of the present invention, the step of delivering the list of software file identifiers to the second node comprises passing the software file identifiers one at a time from the first node to the second node and before each subsequent software file identifier is passed. It involves waiting for a response to an inquiry.
    In another aspect of the present invention, the steps of providing a menu (ie, a software file identifier) to a second node, receiving a response at the first node, and transmitting a desired file from the first node to the second node, respectively, Repeated in two phases, in the first phase, the second node may require a more complex bootstrap program to be downloaded and started. During the download of the second phase, a more complex bootstrap program is run at the second node to decide on another subfile to be accepted from the first node.
    The objects and advantages of the invention are understood by reading the following detailed description associated with the drawings:
    1 (a) and 1 (b) are block diagrams of related components in a cellular telecommunications system for downloading software in accordance with prior art methods.
    2 illustrates components in a cellular communication system including a software package in accordance with the present invention.
    3 is a high level flow diagram of a download operation occurring at a base station controller in accordance with the present invention.
    4 (a) and 4 (b) are more detailed flow diagrams of a first phase download operation executed at a base station controller in accordance with the present invention.
    5 (a) and 5 (b) are more detailed flow diagrams of a second phase download operation executed at a base station controller in accordance with the present invention.
    6 is a flowchart of a download operation executed at a base transceiver station by a subunit in a booting state in accordance with the present invention.
    7 is a flowchart of a download operation executed at a base transceiver station by a subunit in a start state according to the present invention.
    8 is a state transition diagram for the boot and start states of a base transceiver station subunit in accordance with the present invention.
    9 (a) and 9 (b) illustrate the components of a software package used in accordance with the present invention.
    The same features describe the various features of the invention, in relation to the figures identified by the same reference characters. Although the present invention is described with respect to applications in cellular communication systems, it is not limited to such use. In addition, the described embodiments are shown for purposes of explanation only.
    2 illustrates components in a cellular communication system related to the present invention. As shown in the figure, the BSC 201 is connected to a plurality of, i.e., n, BTSs 203-1, ..., 203-n (hereinafter generally referred to as 203). Each BTS 203 includes a plurality of subunits: The BTS 203-1 includes subunits 213-1-1, 213-1-2, ..., 213-1-m 1 ); The BTS 203-n includes subunits 213-n-1, 213-n-2, ..., 213-nm n . In general, the number of subunits 213-x in a given BTS 203- x is represented by the value m x since it is independent of the number of subunits in another BTS. Subunits are generally referred to by reference numeral 213, but this is not intended to mean that each subunit performs the same function. Each subunit 213 includes a processor 217-xy (1 ≦ x ≦ n ; 1 ≦ y ≦ m n ) and a memory for storing the subprogram 219-xy. As described above, the subunits 213-x in the same BTS 203-x are generally said to be different classes because they all have different functions and configurations. The program code to be loaded into a given subunit 213 should be what is intended for the class of the subunit. For example, the subunits 213-1-1 are those of the class base station central function (BCF), and the subunits 213-1-2, ..., (213-1-m 1 ) are class transceivers. (TRX). Since subunits 213 of the same class in different BTSs 203 need not necessarily be identical in configuration, the downloaded SW 219 must also correspond to the subunit type and variant. Since different SW versions may exist for the same configured subunit, different functions can be assigned to the subunit. Typically, higher SW version levels provide more functionality. The SW version level in one subunit 213 is compatible or incompatible with the SW version in another subunit in the same BTS 203. This applies to both SW for the same class and SW for other classes. In addition, since there are versions of the subversion that provide the same functionality but different properties for one class, the selection of the subversion becomes a choice for the operator of the BSC 201 or OSS 233 or for the OSS optimal program. The subunits 213 of the BTS 203 are interconnected by a bus or bus system 214 to communicate with each other in some limited way. In a particular BTS 203, this bus 214 is used for the purpose of transmitting SW downloaded from one subunit to another. However, this functionality does not exist in other BTSs 203.
    According to one aspect of the invention, each subunit 213 is operated in at least one of two states: boot state 801 and start state 803. 8 is a state transition diagram illustrating how various operations to be described later affect the state of the subunit 213.
    In an exemplary embodiment, the BSC 201 is configured to correspond to the corresponding signal transmission paths 215-1-1, ..., (215-1-m 1 ), ..., (215-n-1),. .., each subunit (213-1-1), ..., (213-1-m 1 ), ..., (213-n-1), ... via (215-nm n ) , (213-nm n ) directly. Signal transmission path 215 is a Layer 1 (ie, physical) connection, such as a PCM time slot, with or without another multiplexing. Alternatively, signal transmission path 215 may be comprised of an OSI Layer 2 data link on a physical connection. As is already known in the art, several Layer 2 data links run on the same physical connection. The specific implementation of the signal transmission path 215 is not relevant to the present invention and therefore is not described in more detail herein or shown in FIG. 2. It is also not relevant to the present invention to specifically select the protocols used to realize layer 2 and the data link, thus creating a logically independent signal transmission path between each subunit 213 and BSC 201 of each BTS 203. Applicable to allowable arrays or protocols. Examples of already known data link layers include: LAPD-Integrated Services Digital Network (ISDN) in ETS 300 125; User network interface data link layer specification applications of CCITT Recommendations Q.920 / I.440 and Q.921 / I.441; Layer 2. Presented in LAPB or Signal Transmission System # 7 at CCITT x.25 Logically, all subunits 213 by combining Layer 2 and Layer 1 selection (switching) addressable in signal transmission path 215. ) Is directly connected to the BSC 201 in the form of a star. However, the present invention is not limited to this arrangement, but instead any configuration that accurately controls the subunit 213 with which the BSC 201 communicates (and, of course, the BTS 203 where the subunit 213 is located). It includes.
    In accordance with the present invention, the BSC 201 must be prepared in advance with information identifying which SW package 221 should be downloaded to each BTS 203. In addition, the BSC 201 or OSS 233 may already have a BTS SW package 221 for the BTS 203, possibly for a total of different occurrences of each of the BTSs 203 and / or for the configuration of the producers of each of the BTSs 203. A BTS SW package 221 is supplied to store it.
    The BTS SW package 221 used in the exemplary embodiment is described in more detail in FIGS. 9 (a) and 9 (b). As can be seen in FIG. 9 (a), the BTS SW package 221 is a header file 911 and one or more other subfiles 921-1 which are subprograms to be downloaded to one or more subunits 213. ), ..., and comprises a plurality of subfiles including (921-k). Each subfile 921-1, ..., 921-k is identified by a file revision number FR. For example, in Fig. 9 (a), the first subfile containing a subprogram is identified as FR 1 , and the final file is identified as FR k .
    Like most software, BTS subfiles are regularly updated to keep pace with changes in hardware characteristics and sometimes to suggest purely independent software improvements. This change to be a new version of the software means a change to one or more subfiles out of every subfile intended to work together. In addition, a change in the number of subfiles packaged together may also indicate a new version level. To know these various versions, the file revision number also includes the version number. In one possible way of using this number, it is updated in the unchanged subfile as well as in the changed subfile. This allows all subfiles corresponding to a particular BTS type and variant to have the same version number.
    Further, according to the present invention, the header file 911 is all file revision identifiers corresponding to the file revision numbers of the subfiles 921-1, ..., 921-k included in the BTS SW package 221. And a menu 930 including a list of 931-1, ..., 931-k (see Fig. 9B). Each file revision identifier 931-1, ..., 931-k indicates that the corresponding file is located using the underlying file storage system in BSC 201, or OSS 233 in another embodiment of the present invention. And uniquely identify subfile 921 as a whole in the way it is read.
    According to one embodiment of the invention, the download proceeds in the following method, which is also shown in the flowcharts of FIGS. In another possible embodiment, all steps or portions thereof described herein as being executed in the BSC 201 may be executed in other ways by the OSS 233 executing a signal transmission through the BSC 201 to the BTS 203. have.
    With reference to FIG. 3, the download is initiated by one of a plurality of possible operations (step 301). These actions include, but are not limited to:
    Issue a command from a BSC operator requiring the download operation to be targeted to a single BTS 203-x;
    Issue a command from a BSC operator requiring the download operation to be targeted to a select group of BTS 203;
    Issue a command from a BSC operator requiring the download operation to be targeted to all BTSs 203 connected to BSC 201;
    Issue an instruction from an OSS operator requiring the download operation to be targeted to a single BTS 203-x;
    Issue a command from an OSS operator requiring the download operation to be targeted to a select group of BTS 203;
    Issue a command from an OSS operator requiring the download operation to be targeted to all BTSs 203 connected to BSC 201;
    Receiving by the BSC 201 a report from the BTS 203 indicating that a previous fault has been lost (download initialization is automatically executed by the BSC 201 if such a report is received);
    Detecting by the BSC 201 a signal of a specific BTS malfunction, such as a lack of response to a specific command.
    For each BTS 203-x (1≤x≤n) that is a potential recipient of one or more subprograms 921-1, ..., 921-k, the corresponding header file 911 is Positioned and read into the BSC computer memory (step 303). Next, the first subunit 213-xi (i = 1) associated with the BTS 203-x is selected for processing. Since the test at step 315 (all subunits processed ) Leads to the execution of step 317 (select the next subunit 213-x- (i + 1) for processing), It can be seen that in the BTS 203-x, steps 307 to 313 are executed once for each subunit 213-x-1, ..., (213-xm x ). During execution of steps 307 to 313 for a given subunit 213-xi (1 ≦ i ≦ m x ), the subunit 213-xi using the corresponding signal transmission path 215-xi And messages are exchanged. Although in the exemplary embodiment each subunit 213 is shown to be processed one at a time in succession (by repeated execution of steps 307 to 317), this is not a requirement of the present invention. It will be readily apparent to those skilled in the art that the method described herein can be applied to simultaneously handle all subunits 213.
    In an exemplary embodiment, the processing that occurs in BSC 201 in steps 307 through 313 is designed to perform a two-phase download operation. In the first phase of execution, each subunit 213-xi has the opportunity to use a resident bootstrap program (or an executable application that emulates the bootstrap program in another way) to select a subfile to be downloaded and started. Is given. In accordance with the present invention, the subfile delivered during this phase is itself a bootstrap program capable of executing more complex program load operations than the resident bootstrap program. Therefore, the first phase of execution is followed by a second phase in which each subunit 213-x-i is given the opportunity to select a subfile to be downloaded and started again. However, during the second phase this is the program that was downloaded and started during the first phase of the decision. Of course, the design need not be interrupted in just two phases, but it can be extended to include as many download phases as the designer sees fit for a particular environment.
    Two phases are described in an exemplary embodiment of the invention. In step 307, the BSC 201 invokes the procedure of boot phase query menu name in the header file. This procedure (described in more detail below with reference to Figs. 4 (a) and 4 (b)) proceeds through a header file 911, listing the listed file revision identifiers 931-1, ..., For each of the 931-k, it is determined whether a corresponding one of the subfiles 921-1, ..., 921-k should be delivered to the subunit 213-xi. Execution in step 307 also ensures that the selected subfile is downloaded to subunit 213-x-i. In accordance with a preferred embodiment of the present invention, subfile selection and subsequent download alternates with the subunit 213-xi about the subfile 921-j (1 ≦ j ≦ k), receives the received response and possibly other This is done by conditionally passing the subfile 921-j to the subunit 213-xi according to the information.
    Since the boot phase query menu procedure in the header file is executed without any load (i.e., the subunit 213-xi rejects all of the presented subfile 921), the subunit 213-xi blocks 307. Note that it is not necessary to put the boot state 801 prior to the execution of. Because state transitions trigger other unrelated time consuming processing, such as those associated with hardware test functions, it is advantageous to prevent the subunits 213-xi from unnecessarily entering or leaving the starting state. . Therefore, in an exemplary embodiment, this state transition is minimized. If the subunit 213-xi is in the start state 803 when step 307 begins execution, the boot phase query menu procedure in the header file is selected by the subfile 921-j for download substantially. When the subunit (213-xi) enters the boot state (801).
    After the process in step 307 is completed, the BSC 201 uses the corresponding signal transmission path 215-x-i to send a setting command to the start state to the subunit 213-x-i. This causes the subunit 213-x-i to exit from that state and enter the start state 803 if it was in the boot state 801. The subfile 921-j downloaded as a result of the execution of step 307 now begins execution. According to one aspect of the invention, this downloaded subfile 921-j itself constitutes a bootstrap program that will control which subfile 921-j will be downloaded during the next download phase (hereinafter). To be described).
    Next, in step 311, the BSC 201 enters the second phase of the download process by invoking the start phase query menu procedure in the header file (see later with reference to FIGS. 5 (a) and 5 (b)). Described in more detail). As with the procedure called in step 307, the starting phase query menu procedure in the header file is communicated via the head file 911, and the listed file revision identifiers 931-1, ..., 931-k. For each one, which of the subfiles 921-1,..., 921-k is determined to which subunit 213-xi should be transmitted. Execution in step 311 also ensures that the selected subfile 921 is downloaded to the subunit 213-x-i.
    Following completion of this subfile transfer procedure call, the BSC 201 delivers the end indication of the package to the subunit 213-x-i. As can be seen from the more detailed description below, upon receipt of the end indication of the package by the subunit 213-xi, the subunit 213-xi first determines which of the downloaded files should be started if present. Will start the file.
    Next, as described above, it is determined in step 315 whether the download process has been executed for each subunit 213-x-1, ..., (213-xm x ) in the BTS 203-x. do. In that case, the process is completed at block 319. Otherwise, in step 317, the next subunit 213-x- (i + 1) is selected for the repetitive processing of steps 307 to 313.
    Thus, for each subunit 213-x-i, the BSC 201 executes the subfile query procedure twice: once in step 307 and again in step 311. However, since the receiving subunit 213-xi is in a different state, the other subfiles are downloaded by the starting phase query menu in the header file as compared to those downloaded by the boot phase query menu procedure in the header file, so that each call Run another program while That is, during the execution of step 307, the subunit 213-xi executes the resident boot program in the boot state 801 (or executes the application emulating the resident boot program in the start state 803). . In contrast, during execution of step 311 the subunit 213-x-i is guaranteed to be in the start state 803 as a result of passing the setting command to the subunit 213-x-i in the start state (step 309). In the start state 803, the subunit 213-x-i uses a bootstrap program that has just been downloaded or an initially loaded application program for the purpose of making a download decision in the second phase of the download process.
    4 (a) and 4 (b) illustrate the operation of the boot phase query menu in the header file of the BSC called in step 307 in more detail. This phase 1 subfile delivery procedure begins when invoked (step 401). In step 403, initialization for the procedure is performed by selecting the first file revision identifier 931-j (to j = 1) from the menu 930. Subsequently, in step 405, the BSC 201 uses the signal transmission path 215-xi to deliver a message to the subunit 213-xi, and the subprogram identified by the file revision identifier 931-j. It asks if you want to download it, it is already loaded, or if it is forbidden.
    Subunit 213-x-i generates a response in accordance with the method described later with reference to FIGS. 6 and 7 and returns the response to BSC 201. The response is received by the BSC 201 in step 407, and the boot status answer is extracted in step 409. Since subunit 213-x-i is in start state 803, it does not require a boot state answer to be provided in the response even if this is an operation allowed in start state 803. Thus, in step 411 it is necessary to determine whether a boot status answer is actually given to the received response.
    If a boot state answer is not given in the response, the question may be repeated for this particular subprogram because it is necessary to force subunit 213-x-i to enter boot state 801. Accordingly, in step 413, the signal transmission path 215-x-i is used to transmit the setup command to the boot state to the subunit 213-x-i. Execution then returns to step 405 so that the process may be repeated.
    If the boot status answer is successfully extracted from the response, execution proceeds to step 415 to determine the nature of the answer. If the subunit 213-xi indicates that the subprogram identified by the file revision identifier 931 -j is to be downloaded, execution proceeds directly to step 427, where each file in the menu 930 is located. The test is run to see if the revision identifier 931-j has been processed. In that case, at step 431 the boot phase query menu procedure in the header file is returned to the procedure call point (ie, execution is restarted at step 309). Otherwise, in step 429 the subprogram identified by the next file revision identifier 931 (j + 1) is selected, and execution continues again in step 405.
    In step 415, if it is determined that the subprogram identified by file revision identifier 931-j wants to be downloaded or that subunit 213-xi is indicated as already loaded (i.e., in step 417) Taking the forced path), execution proceeds to step 419. Information from the BSC operator or OSS is used to determine whether the download of subprogram 921-j should be forced in subunit 213-x-i. One example of a situation where download enforcement is appropriate is when the subversion number for a software module to be tested is not recognized as a significantly higher version level than the module to be replaced. In this case, the existing module generates a response indicating that it has already been loaded. Other situations likewise want to force the download of subprogram 921-j in subunit 213-x-i. Since this situation is a particular application, listing it is outside the scope of the present invention.
    If the subprogram identified by file revision identifier 931-j has not already been loaded and forced, execution continues at step 427 as simply described above.
    At the point of executing step 419, it is determined that a download operation occurs. Since the subunit 213-xi must be in a corresponding state (ie, boot state 801) in order to receive the subfile 921 during this download phase, the BSC 201 is assigned to the subunit 213-xi. (Step 419) (in the preferred embodiment, the BSC 201 always knows the current state of each subunit 213), and if the subunit 213-xi is in the start state 803 If found, the BSC 201 first uses the signal transmission path 215-xi to send a setup command to the subunit 213-xi in a boot state. If the subunit 213-x-i is already in the boot state 801, this step is omitted.
    Next, in step 423, the BSC 201 retrieves the subfile 921-j corresponding to the file revision identifier 931-j. This is done by reading a file from storage means located in the BSC 201. According to another feature of the invention, this is done by forwarding the request to OSS 233 having storage means for storing such file in another way. In the latter case, the OSS 233 retrieves the required subfile 921-j from the local storage means and delivers it to the BSC 201.
    Next, in step 425, the BSC 201 uses the signal transmission path 215-x-i to deliver the retrieved subfile 921-j to the subunit 213-x-i. Execution proceeds to a test to determine whether each item in the menu has been processed in step 427. In such case, the procedure is terminated. Otherwise, the next file revision identifier 931 (j + 1) is selected and the loop is repeated.
    5 (a) and 5 (b), this illustrates in more detail the start phase query menu procedure operation in the header file of the BSC called in step 311. This phase 2 subfile delivery procedure begins when invoked similar to the boot phase query menu in the header file (step 501). In step 503, initialization for the procedure is performed by selecting the first file revision identifier 931-j (to j = 1) from the menu 930. Subsequently, in step 505, the BSC 201 uses the signal transmission path 215-xi to deliver a message to the subunit 213-xi, and the subprogram identified by the file revision identifier 931-j. It asks if you want to download it, it is already loaded, or if it is forbidden.
    The subunit 213-xi generates a response according to the method described later with reference to FIG. 7 (as a result of the execution of step 309, ensuring that the subunit 213-xi is in the starting state 803). The response is returned to the BSC 201. The response is received by the BSC 201 in step 507, and the start status answer is extracted in step 509. Since subunit 213-x-i is in start state 803, it is guaranteed that a start state answer will be given.
    Execution then proceeds to step 511 to determine the nature of the response. If the subunit 213-xi indicates that the subprogram identified by the file revision identifier 931-j is prohibited from being downloaded, execution proceeds directly to step 519, where each file in the menu 930 is located. The test is run to see if the revision identifier 931-j has been processed. In such case, at step 523 the start phase query menu procedure in the header file is returned to the procedure call point (ie, execution is restarted at step 313). Otherwise, in step 521 the subprogram identified by the next file revision identifier 931 (j + 1) is selected, and execution continues again in step 505.
    If at step 511 it is determined that the subprogram identified by file revision identifier 931-j is desired to be downloaded or indicated by subunit 213-xi as already loaded (ie, at step 513), Taking the forced path), execution proceeds to step 515. Information from the BSC operator or OSS is used to determine whether the download of subprogram 921-j should be forced in subunit 213-x-i. As mentioned above, one example of a situation where download enforcement is appropriate is when the sub version number for a software module to be tested is not perceived to be a significantly higher version level than the module to be replaced.
    If the subprogram identified by file revision identifier 931-j has not already been loaded and forced, execution continues at step 519 as simply described above.
    At the point of executing step 515, it is determined that a download operation has occurred. Since the subunit 213-x-i is already known to be in the start state 803, the BSC 201 does not need to send a state change command. Therefore, at this point, the BSC 201 retrieves the subfile 921-j corresponding to the file revision identifier 931-j. As above, this is done by reading a file from storage means located in the BSC 201. For another feature of the present invention, this is done by forwarding the request to OSS 233 having storage means for storing such file in another way. In the latter case, the OSS 233 retrieves the requested subfile 921-j from the local storage means and delivers it to the BSC 201.
    Next, in step 517, the BSC 201 has a signal transmission path 215-x-j for delivering the retrieved subfile 921-j to the subunit 213-x-i. Execution proceeds to step 519 to determine whether each item in the menu has been processed. In that case, the procedure ends. Otherwise, the next file revision identifier 931 (j + 1) is selected and the loop is repeated.
    In order to operate as the BSC 201 executing the above-described download procedure, the BTS subunit 213 executes a program which will now be described with reference to Figs. As described above, the subunit 213 can be in one of two states associated with the download procedure: boot state 801 and start state 803 (see FIG. 8). In the booting state 801, the subunit 213 runs a resident bootstrap loader program (for example, a program stored in a nonvolatile memory or an execution application that emulates a bootstrap program). In the start state 803, the subunit 213 runs an application program that has been loaded into the memory. As mentioned above, such an application becomes a more sophisticated bootstrap program to determine which files will be downloaded during the second phase of the download procedure. 8 is a state transition diagram illustrating how the receipt of a particular message affects the state of the subunit 213.
    6 shows the flow of subunit 213 in the current boot state 801. In step 601, the subunit 213 waits for receiving a message from the BSC 201. When the BSC 201 starts executing the boot phase query menu procedure (FIGS. 4A and 4B) in the above-described header file, the subunit 213 is determined by the file revision identifier 931-j. Receive a question message asking whether the identified subprogram is desired to be downloaded, already loaded, or forbidden. This executes step 611 where a question is received by the subunit 213.
    Next, in step 613, the subunit 213 presents a boot status answer. This is done, for example, by using a plurality of known methods (such as calculating a circuit redundancy character (CRC) checksum) to determine whether a valid program file has already been loaded into memory. In that case, the file revision identifier 931-j that was received in the query is compared with the loaded file except for the sub version portion. If the two match, then a reply is sent to the response message that it has already been loaded (step 615). If a currently valid program file is not loaded into the subunit's memory or there is a mismatch, the file revision identifier 931-j indicates that the subunit class, subunit, is valid for the particular subunit 213 that is in the boot state 801. It is analyzed to see if the SW file is related to the variant and the BTS type. In such a case, a response is sent in response to the desired (step 615).
    If none of the answers occur, a response is sent in response to prohibition (step 615). The subunit 213 proceeds back to step 601 where it again waits for another message to arrive.
    If the next message is a new question, the described flow is repeated. If the next message is subfile 921-j, it is received at step 607. Subsequently, in step 609, the received subfile 921-j is processed according to a plurality of known methods such as decompression, execution of CRC summation, decryption, or length checking. Finally, the processed file is stored in the memory of the subunit in which it is executed.
    Reconsidering the situation where the subunit 213 waits for a message from the BSC 201 (step 601), if the next arrival message is a command proceeding to the start state 803, in this case, the command is received (step 605) Start execution of the program file that was stored or found in memory in the boot state 801 (step 606). When execution of the program begins, the state of the subunit 213 changes to the start state 803 as shown by the transition to the input point 1 in FIG.
    Referring to FIG. 7, this is a flowchart showing the operation of the subunit 213 in the start state 803 once. In step 701 it waits to receive a message from the BSC 201. (Of course, the subunit 213 also executes other tasks as indicated by the executing program. The flowchart shows only operations related to the download process.) The program being run was loaded in the boot state 801. (Or found to already reside during the first phase of the download process). This means that the analysis of the question message resides in a loadable program. Therefore, the analysis can be made in a complex way and modified by simple SW changes. In short, this represents all the flexibility of a dynamically loadable control program.
    In other respects, the flow of FIG. 7 is similar to the flow of FIG. 6. The first message that arrives after the set command to start state (step 309) is the question received at step 711. In step 713 the subunit 213 optionally presents a boot status answer in the manner described above for step 613. This is done so that the program running in the start state 803 has the option to provide a response for use during the first phase of the download process.
    Next, in step 715, the subunit 213 presents the start status answer. This operation is not optional. The presentation of the start status response depends entirely on the program that was downloaded (or found to be already loaded) in the boot phase. This step indicates whether the supplied subfile 921-j is accepted (starting state answer = desired) or whether the provided subfile 921-j has already been loaded or prevented from being downloaded (which may be reloaded). It can execute a function that leads to a decision as to whether or not to indicate. For example, the subunit 213 derives the start status answer as a function of the validity of the subfile taking into account the BTS type, the subunit variant, and the subunit class. The subunit 213 also considers the version number of the provided subfile 921-j: consider whether it is equal to, or is lower than, the version currently loaded (if any). Another possible information that can be used is information as to whether the provided version is compatible with the version of another subfile-even the subfile located in another subunit of the BTS 203-x (in order to determine this information the internal network). (214-x) is used).
    After presenting the start status answer, execution proceeds to step 717 where the start status answer and optional boot status response are encoded into a response passed to the BSC 201. According to a preferred embodiment of the present invention, the response is encoded to have a slot dedicated to maintaining the response to the current state and a second slot dedicated to maintaining the response to the other state. Thus, since the subunit 213 is in the current start state 803, the start state answer is encoded into the response slot assigned to the current state, and the boot state response is placed in the response slot assigned to the other state.
    The subunit 213 returns to wait for a message (step 701) and operates as described above for the boot state 801 (see FIG. 6). That is, when the subfile 921-j arrives, the subunit 213 processes and stores it as described above with respect to steps 607 and 609 (steps 707 and 709).
    When a new question message arrives, it is processed by steps 711 to 717 as described above.
    When the end indication of the package arrives (delivered by the BSC 201 in step 313), it is received, and the subunit 213 decides which of the programs currently loaded in the memory should be started. Use a specific application routine (steps 703 through 704). However, the state of the subunit 213 remains unchanged, and any routine running in the determination of step 706 ensures that step 701 is executed to resume the next message wait. That is, a new program that takes over control from the currently executed program should be able to execute the steps described in FIG.
    When the setting command arrives in the boot state, the subunit 213 receives the command (step 705) and starts execution of the resident bootstrap program (step 706). Alternatively, the subunit 213 may begin executing an application that emulates a resident bootstrap program. In any case, the state of the subunit 213 changes to the boot state 801, as shown by the transition to input point 2 in FIG. 6.
    In another aspect of the invention, only one of the subunits 213-xi in the BTS 203-x allows the subfile 921-j to be loaded. The remaining subunits 213-xy (2 ≦ y ≦ m x ) always respond with a prohibited state in response to each question, regardless of whether they are in the boot state 801 or the start state 803. In this example, the first subunit 213-x-1 receives all subfiles 921 for the BTS 203-x, and the other subunit 213-xy through the internal network 914-x. It is responsible for distributing it.
    According to another feature of the invention, the phase number of the download process can vary. That is, it can be reduced to only one question processing (one question per subfile 921) or increased to three or more phases. The present invention includes the possibility of effectively reducing the number of phases to only one by performing all file transfers during one phase and by allowing the subunit 213 to reject all subfiles 921-j provided during all other download phases. Note that
    Moreover, the number of phases can change dynamically based on the response information received from the BTS subunit 213. It may also be based on information possibly added per file revision identifier 931-j in the header file.
    In another embodiment of the present invention, the subunits 213-x-i do not have to be processed sequentially. In addition, the BSC 201 may deliver the question in parallel to some or all of the subunits 213.
    In another embodiment of the present invention, the BSC 201 may send the subunit 213-to the first subfile 921-j before passing a question about the next subfile 921-(j + 1). There is no need to wait for a response from x). Instead, the BSC 201 may deliver the entire list of file revision identifiers 931 to the subunit 213-x-i all at once. This has the advantage of allowing the subunit 213-x-i to fully read the entire list before engaging in receiving the particular subfile 921. Those skilled in the art can readily modify the exemplary embodiment of FIGS. 3-7 to achieve embodiments of this alternative method of the present invention. For example, the BSC 201 delivers each file revision identifier 931 to the subunit 213-xi, followed by an end indication of the package, and the subunit 213-xi is assigned to all file revision identifiers 931. A routine may be designed to know that it has been received. When the end indication of the package is received, the subunit 213-x-i reads the list sufficiently, selects it and encodes it in response. When the response is received, the BSC 201 can retrieve and forward the required subfile 921 as described above.
    As mentioned above, the present invention has a number of advantages over the prior art methods for downloading software. For example, this may mean that the software package consists of several subfiles, and also that downloads can occur across several transport paths, each ending in a different subunit 213-xi of the BTS 203-x. Consider all of the possibilities.
    Moreover, the present invention does not require a one-to-one correspondence between subunits and subfiles. Since the techniques of the present invention allow a subunit to reject or accept a provided subfile, the subfiles can be grouped into packages that do not depend on the requirements of one subunit.
    The present invention has been described with reference to specific embodiments. However, it will be readily apparent to one skilled in the art that the present invention may be embodied in specific forms other than the preferred embodiments described above. This can be done without departing from the intention of the present invention. Preferred embodiments are merely illustrative and should not be considered as limiting in any way. The scope of the present invention is given by the appended claims rather than the foregoing description, and all modifications and equivalents falling within the scope of the claims are intended to be included therein.
    权利要求:
    Claims (16)
    [1" claim-type="Currently amended] A method for supplying a second node with one or more software files desired in a networked system comprising a first node coupled to a second node:
    Retrieving at a first node a menu comprising a list of respective software file identifiers identifying a corresponding one of the plurality of software files;
    Passing a list of software file identifiers from the first node to the second node;
    Examining, at the second node, each software file identifier and forming a response for each software file identifier including an indication that a corresponding one of the plurality of software files is desired or not desired;
    Forwarding the response from the second node to the first node;
    Examining, at the first node, the response and retrieving a corresponding one of the plurality of software files that has been marked as desired at the second node; And
    Delivering the retrieved software file from the first node to the second node.
    [2" claim-type="Currently amended] The method of claim 1,
    The indication that the corresponding one of the plurality of software files is not desired is an indication that the corresponding one of the plurality of software files has already been loaded on the second node, or that the corresponding one of the plurality of software files is prohibited from being loaded on the second node. One of the indications.
    [3" claim-type="Currently amended] The method of claim 1,
    The networked system is a cellular telephone system, the first node is a base station controller, and the second node is a base transceiver station;
    The base station controller includes storage means for storing a plurality of software files; And
    At the first node, retrieving a corresponding one of the plurality of software files corresponding to the software file identifier that was indicated as desired by the second node is the software file that was marked as desired by the second node of the plurality of software files. Retrieving from the local storage means corresponding to the identifier.
    [4" claim-type="Currently amended] The method of claim 1,
    The networked system is a cellular telephone system, the first node is a base station controller, and the second node is a base transceiver station; And
    At the first node, retrieving a plurality of software files corresponding to a software file identifier that has been marked as desired by the second node:
    Forwarding a request from the first node to the operational support system for corresponding to a software file identifier that was indicated as desired by the second node of the plurality of software files;
    In the motion support system, retrieving a required software file; And
    Delivering the retrieved software file from a motion support system to a first node.
    [5" claim-type="Currently amended] The method of claim 1,
    Passing the list of software file identifiers to a second node comprises:
    a) selecting a first software file identifier from a list of software file identifiers to use as the current software file identifier;
    b) passing the current software file identifier from the first node to the second node;
    c) waiting for a response from the second node;
    d) after receiving the response from the second node, selecting the next software file identifier from the list of software file identifiers to use as the current software file identifier; And
    e) repeating steps b) to d) until each software file identifier in the list of software file identifiers is passed from the first node to the second node.
    [6" claim-type="Currently amended] The method of claim 5,
    Step d) is:
    After receiving the response from the second node, waiting for the response to be examined at the first node;
    Waiting for a corresponding one of the plurality of software files to be retrieved at the first node corresponding to the software file identifier that was indicated as desired by the second node;
    Waiting for the retrieved software file to be transferred from the first node to the second node; And
    Selecting from the list of software file identifiers the next software file identifier to use as the current software file identifier.
    [7" claim-type="Currently amended] In a networked system comprising a first node connected to a second node, the method of supplying the desired one or more software files to the second node:
    Retrieving at a first node a menu comprising a list of respective software file identifiers identifying a corresponding one of the plurality of software files;
    Passing a list of software file identifiers from the first node to the second node;
    At the second node, use the resident program to examine each software file identifier, and for each soft file identifier, include a first indication of whether the corresponding one of the plurality of soft files is desired or not desired by one of the two. Forming a first response;
    Forwarding the first response from the second node to the first node;
    Examining, at the first node, the first response and retrieving a corresponding one of the plurality of software files that has been marked as desired at the second node;
    Transferring the retrieved software file from the first node to the second node;
    At a second node, starting execution of a software file received from the first node;
    Passing the list of software file identifiers from the first node to the second node during the second time;
    At the second node, use the executable software file that was received from the first node to examine each software file identifier, and for each soft file identifier a corresponding one of the plurality of soft files is desired or not desired. Forming a second response comprising a second indication;
    Passing a second response from the second node to the first node;
    Examining, at the first node, the second response and retrieving a corresponding one of the plurality of software files that has been indicated in the second response as desired at the second node; And
    Delivering from the first node to the second node a software file that was retrieved as a result of examining the second response at the first node.
    [8" claim-type="Currently amended] The method of claim 7, wherein
    Each of the first and second indications that a corresponding one of a plurality of software files is not desired is an indication that a corresponding one of the plurality of software files is already loaded in the second node, or a corresponding one of the plurality of software files is the second. One of the indications that it is forbidden to load on the node.
    [9" claim-type="Currently amended] An apparatus for supplying a second node with one or more software files desired in a networked system including a first node coupled to a second node:
    At the first node:
    Means for retrieving a menu comprising a list of respective software file identifiers identifying a corresponding one of the plurality of software files; And
    Means for conveying a list of software file identifiers from a first node to a second node;
    At the second node:
    Means for examining each software file identifier and forming a response for each software file identifier including an indication of whether a corresponding one of the plurality of soft files is desired or not desired; And
    Means for forwarding the response from a second node to a first node,
    The first node is:
    Means for examining the response and retrieving a corresponding one of the plurality of software files that has been marked as desired at the second node; And
    And means for transferring the retrieved software file from the first node to the second node.
    [10" claim-type="Currently amended] The method of claim 9,
    The indication that the corresponding one of the plurality of software files is not desired is either an indication that the corresponding one of the plurality of software files is already loaded on the second node, or the corresponding one of the plurality of software files is prohibited from being loaded on the second node. A device that is one of the indications.
    [11" claim-type="Currently amended] The method of claim 9,
    The networked system is a cellular telephone system, the first node is a base station controller, and the second node is a base transceiver station;
    The base station controller includes storage means for storing a plurality of software files; And
    At the first node, the means for retrieving the corresponding one of the plurality of software files corresponding to the software file identifier that was indicated as desired by the second node is the software file that was indicated as desired by the second node of the plurality of software files. Means for retrieving from the local storage means corresponding to the identifier.
    [12" claim-type="Currently amended] The method of claim 9,
    The networked system is a cellular telephone system further comprising an operational support system coupled to the first node;
    The first node is a base station controller;
    The second node is a base transceiver station;
    At said first node, means for retrieving a corresponding one of a plurality of software files corresponding to a software file identifier that has been indicated as desired by a second node of the plurality of software files has been indicated as desired by the second node of the plurality of software files. Means for forwarding a request for corresponding to the file identifier from the first node to the operational support system; And
    The motion support system is:
    Means for retrieving the required software file; And
    Means for delivering the retrieved software file from the motion support system to the first node.
    [13" claim-type="Currently amended] The method of claim 9,
    Means for conveying the list of software file identifiers to the second node are:
    Means for selecting a first software file identifier from a list of software file identifiers for use as a current software file identifier;
    Means for conveying a current software file identifier from the first node to the second node;
    Means for waiting for a response from the second node; And
    In response to receiving a response from the second node, a list of software file identifiers, the following software file identifiers, for use as current software file identifiers by means of transferring a current software file identifier from the first node to the second node. Means for selecting from the;
    [14" claim-type="Currently amended] The method of claim 9,
    Means for conveying the list of software file identifiers to the second node are:
    Means for selecting a first software file identifier from a list of software file identifiers for use as a current software file identifier;
    Means for conveying a current software file identifier from the first node to the second node;
    Connected to a means for searching and retrieving and for retrieving a retrieved software file from the first node to the second node, the corresponding software file identifier being marked as desired by the second node of the plurality of software files. Waiting means for waiting to be retrieved and passed from the first node to the second node, and generating an output when the waiting is completed; And
    In response to the output of the waiting means, selecting a next software file identifier from a list of software file identifiers to use as a current software file identifier by means of transferring a current software file identifier from the first node to the second node. A device comprising means.
    [15" claim-type="Currently amended] An apparatus for supplying a second node with one or more software files desired in a networked system including a first node coupled to a second node:
    At the first node:
    Means for retrieving a menu comprising a list of software file identifiers, where each software file identifier identifies a corresponding one of the plurality of software files; And
    Means for conveying a list of software file identifiers from the first node to the second node;
    At the second node:
    Use the resident program to examine each software file identifier and form a first response for each soft file identifier comprising a first indication that the corresponding one of the plurality of soft files is desired or not desired. Means for doing so; And
    Means for forwarding the first response from the second node to the first node,
    The first node is:
    Means for investigating the first response and searching for a corresponding one of a plurality of software files that has been marked as desired at the second node;
    Means for transferring the retrieved software file from the first node to the second node; And
    Means for conveying a list of software file identifiers from the first node to the second node during a second time period,
    The second node is:
    Means for initiating execution of a software file received from the first node;
    Using an executable software file received from the first node to examine each software file identifier, and for each soft file identifier, a second indication that a corresponding one of a plurality of soft files is desired or not desired Means for forming a second response comprising a; And
    Means for forwarding the second response from the second node to the first node,
    The first node is:
    Means for examining the second response and retrieving a corresponding one of a plurality of software files that has been indicated in the second response as desired at the second node; And
    And means for transferring from the first node to the second node a software file that was retrieved as a result of examining the second response at the first node.
    [16" claim-type="Currently amended] The method of claim 15,
    Each of the first and second indications that a corresponding one of a plurality of software files is not desired is either an indication that a corresponding one of the plurality of software files is already loaded in the second node, or a corresponding one of the plurality of software files. A device that is an indication that it is forbidden to load on a node.
    类似技术:
    公开号 | 公开日 | 专利标题
    JP5507497B2|2014-05-28|Trigger event processing
    EP2578005B1|2020-04-08|Method and apparatus for the management of non volatile items and provisioning files for a communication device with multiple service accounts
    US8285270B2|2012-10-09|Wireless communication apparatus, wireless communication network and software upgrading method
    US6493871B1|2002-12-10|Method and system for downloading updates for software installation
    US6978453B2|2005-12-20|System with required enhancements to syncML DM environment to support firmware updates
    KR100450473B1|2004-10-01|Device registry server for automatic connection and data exchange between pervasive devices and backend systems
    DE69832978T2|2006-07-06|System and method for personalizing cordless transmission units
    US6643506B1|2003-11-04|Wireless software upgrades with version control
    US9141366B2|2015-09-22|Method, system, terminal and device management server for installing software components
    DE19882411B3|2015-02-26|Background software load in cellular telecommunication systems
    US5754785A|1998-05-19|Communications network equipment
    TWI281803B|2007-05-21|Method for providing a communication device, communication device, system in a wireless network, and computer readable medium
    JP3317405B2|2002-08-26|Telecommunication switch with programmable network protocols and communication services
    KR100392884B1|2003-07-28|Open “plug play” o m architecture for a radio base station
    EP0872138B1|2007-08-01|Upgrading software in a mobile telephone
    US8045971B2|2011-10-25|Communications network capable of determining SIM card changes in electronic devices
    US7320010B2|2008-01-15|Controlling updates of electronic files
    US7809364B2|2010-10-05|Apparatus, and associated method, for providing an operation parameter to a mobile station of a radio communication station
    US5848128A|1998-12-08|Telecommunications call preservation in the presence of control failure
    DE19543843C2|2001-02-08|Procedure for updating the software in a microcomputer-based telephone
    EP1236319B1|2007-10-24|Packet and circuit switched network method and apparatus
    US6327355B1|2001-12-04|Use of platform-independent code for supporting services in an intelligent network
    KR100825348B1|2008-04-28|Server system and online software update method
    US7752618B2|2010-07-06|Apparatus and method for remote DLL linking of software upgrades for a wireless mobile station
    US7941656B2|2011-05-10|Card device for loading applications to a mobile device
    同族专利:
    公开号 | 公开日
    DE69632031D1|2004-05-06|
    AU4637996A|1996-08-21|
    AU702231B2|1999-02-18|
    CA2211733A1|1996-08-08|
    WO1996024231A1|1996-08-08|
    EP0807363A1|1997-11-19|
    FI973143A0|1997-07-29|
    FI973143A|1997-09-29|
    FI973143D0|
    JPH11501136A|1999-01-26|
    RU2155372C2|2000-08-27|
    CN1179254A|1998-04-15|
    CN1089538C|2002-08-21|
    EP0807363B1|2004-03-31|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    法律状态:
    1995-01-30|Priority to US38079495A
    1995-01-30|Priority to US8/380794
    1996-01-30|Application filed by 얼링 블로메, 클라스 노린, 텔레호낙티에볼라게트 엘엠 에릭슨
    1998-06-25|Publication of KR19980701680A
    优先权:
    申请号 | 申请日 | 专利标题
    US38079495A| true| 1995-01-30|1995-01-30|
    US8/380794|1995-01-30|
    [返回顶部]